1. Field of the Invention
The present invention relates to interfacing between service providers and secure elements, and more particularly to systems, methods, and computer program products for interfacing between service provider trusted service managers and secure elements.
2. Related Art
A service provider (SP) is a company, organization, entity, or the like, that provides services to customers or consumers. Examples of service providers include account-issuing entities such as merchants, card associations, banks, marketing companies, and transit authorities. A service may be an activity, capability, functionality, work, or use that is permitted or provided by a service provider such as a payment service, a gift, offer or loyalty service, transit pass service, and the like.
In a mobile environment that involves contactless transactions between a mobile device and a service provider, information relating to the accounts and applications issued by the service providers must be downloaded onto mobile devices in order to enable them to perform the contactless transactions.
A trusted service manager (TSM) is typically an independent entity serving mobile network operators (MNOs) and account-issuing service providers by provisioning applications, such as contactless applications associated with the service providers, to mobile devices. Typical TSMs can distribute and manage the contactless applications remotely because they have access to secure elements (SEs) in a near field communication (NFC) enabled mobile device.
Security-critical applications, such as those involving payment and account credentials, require secure hardware storage and a secure execution environment. On mobile devices, this is usually handled by the secure element.
The secure element is a platform onto which applications can be installed, personalized and managed. It consists of hardware, software, interfaces, and protocols that enable the secure storage of credentials and execution of applications for payment, authentication, and other services.
A secure element may be implemented in different form factors such as a Universal Integrated Circuit Card (UICC), an embedded secure element, or NFC enablers such as a separate chip or secure device, which can be inserted into a slot on the mobile device. Typically a UICC is in the form of a subscriber identity module (SIM), which is controlled by the MNOs. An embedded secure element gives service providers the option to embed the secure element into the phone itself. One way in which secure element form factors are implemented is defined in, for example, GlobalPlatform Card Specification Versions 2.1.1 and 2.2 (hereinafter “Global Platform”).
A secure element may include one or more security domains (SDs), each of which includes a collection of data, such as packages, applets, applications, and the like, that trust a common entity (i.e., are authenticated or managed using a common security key or token).
Security domains may be associated with service providers and may include service provider applets or applications such as loyalty, couponing, and credit card, and transit applications or applets.
Traditionally, service provider systems include a TSM to interconnect with a secure element on a mobile device to create a security domain on the secure element and install, provision and manage applets and applications on the secure element. Service providers must be able to provide their services to a large number of customers with different mobile devices, equipped with different secure elements, and being serviced by a variety of MNOs. As explained above, secure elements may be implemented in numerous form factors, and may contain a variety of security domains, applets and applications, all potentially configured in an extremely large number of ways. As a result, service providers are faced with the overwhelming task of providing adaptable services and solutions to a large, and often growing and changing, combination of mobile devices, MNOs, networks, secure elements and security domains.
For example, in order for a service provider to securely install a payment applet onto a customer's secure element on a mobile device, the service provider must first determine a large amount of information in order to send to and process a request on a secure element. For example, service providers using the prior art must obtain secure element information (e.g., identifiers, type, profile identifier, certification level and expiration), MNO information (e.g., type), security domain information (e.g., identifier, privileges, master key index), and the like. This information may exist in a variety of different sources (e.g., security domain, secure element, mobile device, MNO) and therefore, it is a laborious task for a service provider to retrieve, and check for parity, all of this information, requiring extensive processing.
One technical challenge in the installation, management, and provisioning of applications on secure elements is due to the limitations in typical TSMs, namely that they do not function as central intermediaries capable of processing communications between a large variety of service providers, MNOs, mobile devices, networks, secure elements and security domains. There is a need, therefore, for an improved system such as a central TSM, particularly tailored for interfacing between service providers (including service provider TSMs) and secure elements.
From the perspective of a service provider, what matters is that they can easily and securely communicate (i.e., request personalization, service activation, processing of scripts, etc.) with an intended customer's secure element, regardless of the customer's mobile device, secure element, MNO, or mobile network.
From the perspective of the customer, what matters is that the service of the service provider can be activated on and used with the customer's secure element, regardless of the customer's mobile device, secure element, MNO, or mobile network.